The present invention relates in general to digital processing and more specifically to an application model for the use of dynamic computing environments in various phases of software lifecycle.
In the past, software providers shrink-wrapped software in digital media, such as floppy disks or CD-ROMs, for distribution to customers. Thus, distribution involved one copy of the software per customer.
With the arrival of the Internet, distribution by downloading was made possible, but software was still packaged as an entity that has to reach each individual customer. Thus, a new mode of software—the ‘Web site’— was made available. The Web site is a limited abstraction of a client-server software model where the clients were now universal web clients, i.e., browsers, and the servers had limited and focused functionality, i.e., searching, messaging, transacting, etc. In this model, browsers did not depend on the specific software running on any web site or the specific service provided by any web site. Thus, the new distribution model for software was the exact reverse of the older model—all customers (virtually) travel to the web site to use the software instead of the software going to the customer(s). Therefore, a single copy of the server software was used for many customers (without distribution) and client software was available/applicable universally. This reversal entailed a fundamental shift in the underlying model of computation in that most data (search catalogs, emails, product catalogs) were generated and/or stored at the provider end and almost all of the computation happened at the provider end. This was different from the traditional model where all the data were generated and stored on the customer end and all the computation happened on the customer end. Even in the traditional client-server setting, both the client and the server were typically located in the customer end.
The maturity of Internet/Web software and the increased availability of cheaper communication bandwidth have resulted in another model of software distribution: the Application Service Provider (ASP) model, also known as the ‘Software as Service’ model. The model fills a continuum between the two models described above: software can be located completely at the provider end or can be modularized so that some parts are located at the provider end and the rest at the customer end. In this model, data may be generated at the customer end, the provider end, or both. Additionally, computation may happen at either end or can be distributed in parts. Thus, either a single copy of the software may be used for many customers or each customer may receive a copy of some parts of the software. Also, computation may even be mobile, i.e., computation may be switched dynamically—back and forth—between the provider and customer ends. This implies on-the-fly distribution of copies of parts of the software to individual customers.
The typical lifecycle of software includes the following phases: development, integration, testing, beta testing, beta deployment, staging, and deployment. Additionally, this list does not include phases like Requirements Analysis or Design that typically do not involve computing resources. Also, all these phases may not apply to all three of the software models discussed above and even when they do apply, they may be highly dissimilar in nature. For instance, staging is not a typical phase for shrink-wrapped software. As another example, deployment of shrink-wrapped software involves deployment in various customer environments while deployment of web-site software involves hosting in the provider environment, and further deployment of ASP software may involve a combination of both of these and infrastructure for enabling distributed/mobile computation.
A given software model will entail a spectrum of computing needs and constraints to cover the various phases of the lifecycle. For instance, the development phase of the lifecycle may need many copies of one type of configuration; while the testing phase may need one copy of many types of configurations. In order to meet the different needs of each phase of the lifecycle, a provider must manually set up the computing requirements for each phase. For example, in the development phase, many copies of the one type of configuration must be loaded onto a number of computers for development to be done. Once the development stage has been completed, the testing phase may require many types of configurations. The different configurations either need to be manually loaded onto the same computers used in the development stage or other computers with the desired configurations must be found and set up.
The different requirements of each phase of the software lifecycle presents problems in relation to manpower, computing power, and flexibility. For example, administrators are needed to address the changing computing needs of each phase. Additionally, administrators physically set up the computers required for each phase. With regard to computing power, certain phases may require more powerful machines than other phases, which may cause cost and space restrictions on a provider. For example, the testing phase may require the use of many workstations and the development phase may require the use of a personal computer. Because of the high cost of workstations, a provider may not be able to purchase an adequate number of workstations or may not be able to justify purchasing a large number of workstations for only one phase of the software lifecycle. Further, a provider is limited to using the actual machines that are present at the site of the stage of the lifecycle. Thus, new machines cannot be used during a stage without physically importing them into the site.
The computing requirements of each phase may be different from other phases. Thus, moving from one phase to another results in reconfiguration of computing environments. The physical reconfiguration results in waste of manpower (i.e., systems administrators) and delays in the lifecycle itself.